הרצת ווים לפני ואחרי פריסה

במאמר הזה מוסבר איך להריץ תוכניות או פעולות שרירותיות לפני או אחרי הפריסה.

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

אפשר להגדיר כל ווּב-הוּק להפעלה בסביבת ביצוע ספציפית של Cloud Deploy, אבל אם אתם פורסים ל-Google Kubernetes Engine, אתם יכולים גם להגדיר אותו להפעלה באשכול GKE שבו אתם פורסים את האפליקציה.

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

איך פועלים ווים של פריסה?

בקטע הבא מוסבר איך פועלות נקודות ההרחבה של הפריסה ב-Cloud Deploy ואיך מגדירים אותן:

  1. אתם מגדירים ווּקים בשלב אחד או יותר בתהליך של צינור העברת הנתונים.

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

    ה-hook‏ predeploy תמיד מופעל כעבודה הראשונה בשלב.

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

הפעולות של וו פריסה מבוצעות בסביבת ההפעלה של Cloud Deploy.

שימוש ב-deploy hooks עם פריסה של גרסה ראשונית (canary)

כשמגדירים deploy hooks לפריסה של גרסה ראשונית (canary), יש כמה דברים שחשוב לדעת:

  • בשלב של צינור העברת הנתונים, ההגדרה של ה-hook (predeploy ו-postdeploy) נמצאת בקטע strategy.canary.canaryDeployment או strategy.canary.customCanaryDeployment.phaseConfigs, ולא בקטע strategy.standard.

  • בפריסת קנרית אוטומטית, ווים של predeploy מופעלים לפני הפריסה רק בשלב הראשון, וווים של postdeploy מופעלים אחרי הפריסה רק בשלב האחרון (יציב).

הגדרת צינור עיבוד הנתונים להרצת hooks

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

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

serialPipeline:
  stages:
  - targetId: hooks-staging
    profiles: []
    strategy:
      standard:
        predeploy:
          tasks: [TASKS]
        postdeploy:
          tasks: [TASKS]

בקובץ ה-YAML הזה:

  • TASKS

    רשימה של משימות אחת או יותר שרוצים להפעיל כחלק מה-hooks של predeploy או postdeploy. אם מציינים יותר ממשימה אחת, הן מתבצעות ברצף, לפי הסדר שבו הן מוגדרות. העבודה (לפני הפריסה או אחרי הפריסה) נכשלת במשימה הראשונה שנכשלת, והמשימות שנותרו לא מופעלות.

הפעלת ה-hooks באשכול האפליקציות

כברירת מחדל, ווים של פריסה פועלים בסביבת ההפעלה של Cloud Deploy. אפשר גם להגדיר את Skaffold להפעיל deploy hooks באותו אשכול שבו האפליקציה פועלת.

כדי להפעיל hooks באשכול האפליקציות, צריך להגדיר אותם כ-customActions בקובץ skaffold.yaml, ולהפנות אליהם באמצעות actions בקטע predeploy או postdeploy בהגדרת השלב של צינור ההפצה:

serialPipeline:
  stages:
  - targetId: hooks-staging
    profiles: []
    strategy:
      standard:
        predeploy:
          actions: ["my-predeploy-action"]
        postdeploy:
          actions: ["my-postdeploy-action"]

האפשרות הזו זמינה רק לפריסות ב-GKE, ולא ב-Cloud Run. פריסות ב-Cloud Run יכולות להריץ hooks רק בסביבת ההפעלה של Cloud Deploy.

כדי להגדיר את ה-hook להרצה באשכול, צריך לכלול את ה-stanza‏ executionMode.kubernetesCluster בקובץ ההגדרות skaffold.yaml, בתוך ה-stanza‏ customActions של כל פעולה שרוצים להריץ באשכול:

customActions:
- name: ACTION_NAME
  containers:
  - name: CONTAINER_NAME
    image: IMAGE
    command: [COMMANDS_TO_RUN]
    args: [LIST_OF_ARGS]
  executionMode:
    kubernetesCluster: {}

בדוגמה הבאה מוצג קטע customActions שכולל את executionMode כדי להפעיל את מארח ה-hook באשכול האפליקציה:

customActions:
- name: predeploy-action
  containers:
  - name: predeploy-echo
    image: ubuntu
    command: ["/bin/sh"]
    args: ["-c", 'echo "this is a predeploy action"' ]
  executionMode:
    kubernetesCluster: {}

הקטע executionMode הוא אופציונלי, ואם משמיטים אותו, Skaffold מפעיל את קונטיינר הפעולה המותאמת אישית בסביבת ההפעלה של Cloud Deploy.

משתני סביבה זמינים

‫Cloud Deploy גם מספק ומאכלס את משתני הסביבה הבאים בסביבת הביצוע. אפשר להשתמש במשתני הסביבה האלה כחלק מה-deploy hook, מהאימות של העבודה או מהיעד המותאם אישית שלכם.

  • ANTHOS_MEMBERSHIP

    עבור יעדים מהסוג ANTHOS, שם המשאב המלא של החברות ב-Anthos.

  • CLOUD_RUN_LOCATION

    למטרות מסוג RUN, האזור שבו שירות Cloud Run נפרס.

  • CLOUD_RUN_PROJECT

    למטרות מסוג RUN, הפרויקט שבו נוצר שירות Cloud Run.

  • CLOUD_RUN_SERVICE

    עבור יעדים מסוג RUN, השם של שירות Cloud Run שנפרס.

  • CLOUD_RUN_SERVICE_URLS

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

  • CLOUD_RUN_REVISION

    למטרות מסוג RUN, הגרסה הספציפית של שירות Cloud Run.

  • GKE_CLUSTER

    עבור יעדים מסוג GKE, שם המשאב שצוין במלואו של אשכול Google Kubernetes Engine, לדוגמה projects/p/locations/us-central1/clusters/dev.

  • TARGET_TYPE

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

  • CLOUD_DEPLOY_LOCATION

    האזור שמכיל את המשאבים של Cloud Deploy.

  • CLOUD_DEPLOY_DELIVERY_PIPELINE

    המזהה של צינור העברת הנתונים.

  • CLOUD_DEPLOY_TARGET

    המזהה של היעד.

  • CLOUD_DEPLOY_PROJECT

    מספר הפרויקט ב- Google Cloud שמכיל את המשאבים של Cloud Deploy.

  • CLOUD_DEPLOY_PROJECT_ID

    מזהה הפרויקט Google Cloud של הפרויקט.

  • CLOUD_DEPLOY_RELEASE

    המזהה של הגרסה שבה יופעלו ה-hooks.

  • CLOUD_DEPLOY_ROLLOUT

    המזהה של ההשקה שכוללת את המשימות של ה-hooks.

  • CLOUD_DEPLOY_JOB_RUN

    המזהה של הפעלת המשימה שמייצג את ההרצה הנוכחית של המשימה.

  • CLOUD_DEPLOY_PHASE

    השלב בהשקה שכולל את העבודה של ה-hook לפריסה, עבודת האימות או עיבוד או פריסה בהתאמה אישית.

פריסת פרמטרים כמשתני סביבה

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

מידע נוסף

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