שימוש בכללים אוטומטיים

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

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

כללים אוטומטיים זמינים

אלה הכללים לאוטומציה שזמינים ב-Cloud Deploy:

כלל תיאור
timedPromoteReleaseRule קידום אוטומטי מיעד אחד ליעד הבא

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

ההשקה ביעד הקודם בתהליך ההתקדמות.
advanceRolloutRule ההפצה מתקדמת באופן אוטומטי מהשלב שצוין

שלב לשלב הבא.
repairRolloutRule ניסיון חוזר אוטומטי של המשימה או המשימות שנכשלו בהשקה

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

הגדרת כללים לאוטומציה

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

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

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

הגדרת timedPromoteReleaseRule כלל אוטומטי

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

rules:
- timedPromoteReleaseRule:
    id: "[RULE_ID]"
    schedule: "[CRON]"
    timeZone: "[TIME_ZONE]"
    destinationTargetId: "[TO_TARGET]"
    destinationPhase: "[TO_PHASE]"

כאשר:

  • [RULE_ID]

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

  • [CRON]

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

    התזמון הזה משתמש בתחביר הרגיל cron:

    * * * * *

    בלוח הזמנים הזה…

    • המיקום הראשון הוא הדקה (0-59).
    • המיקום השני הוא השעה (0-23).
    • המיקום השלישי הוא היום בחודש (1 עד 31).
    • המיקום הרביעי הוא החודש (1-12).
    • המיקום החמישי הוא היום בשבוע (0-6, ראשון עד שבת)

    לדוגמה, אם הכלל לקידום מתוזמן כולל את לוח הזמנים הבא: 0 9 * * 1, הגרסה שלכם תקודם בכל יום שני בשעה 9:00.

    אפשר גם להשתמש בתכונות של תזמון cron רגיל, כמו:

    • טווח (0-5)
    • רשימה (1,3,5)
    • פונקציית מדרגה (לדוגמה, */3 בשדה השעות מפעילה כל שעה שלישית)

  • [TIME_ZONE]

    אזור הזמן שרוצים להשתמש בו לתזמון המבצע, בפורמט IANA.

  • [TO_TARGET]

    האם targetId של היעד שאליו רוצים לקדם, או @next כדי לקדם את הגרסה באופן אוטומטי ליעד הבא אחרי היעד שצוין ב-selector.targets property בהגדרת האוטומציה הזו. הפעולה הזו אופציונלית. ברירת המחדל היא @next.

  • [TO_PHASE]

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

הגדרת promoteReleaseRule כלל אוטומטי

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

כשמגדירים אוטומציה של promoteReleaseRule, אפשר לציין יעד לקידום (destinationTargetId) או @next. כשההשקה מסתיימת בהצלחה ביעד שצוין בהגדרה של Automation, הגרסה מקודמת ליעד שצוין ב-destinationTargetId, בכפוף למרווח הזמן wait.

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

rules:
- promoteReleaseRule:
    id: "[RULE_ID]"
    wait: [WAIT_TIME]
    destinationTargetId: "[TO_TARGET]"
    destinationPhase: "[TO_PHASE]"

כאשר:

  • [RULE_ID]

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

  • [WAIT_TIME]

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

    ערך ברירת המחדל הוא 0, כלומר אין זמן המתנה. הערך המקסימלי הוא 20160m (או 14 ימים).

  • [TO_TARGET]

    האם targetId הוא היעד לקידום?

    אפשר גם להשתמש בערך @next, שמקדם את הגרסה באופן אוטומטי ליעד הבא אחרי היעד שצוין במאפיין selector.targets בהגדרת האוטומציה הזו. זה ערך ברירת המחדל אם לא מציינים ערך במאפיין destinationTargetId.

  • [TO_PHASE]

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

הגדרת advanceRolloutRule כלל אוטומטי

הלחצן advanceRolloutRule מקדם את ההשקה באופן אוטומטי לשלב הבא אחרי ששלב מסוים מסתיים בהצלחה. כלל האוטומציה הזה שימושי לפריסות קנריות. לדוגמה, אם הגדרתם אסטרטגיית פריסה מסוג Canary על יעד, עם שלבים של 25%, 50% ו-stable, תוכלו להגדיר כלל אוטומטי שיעביר את השלב אוטומטית ל-stable אחרי שהשלב 50% יסתיים.

כשמגדירים advanceRolloutRule אוטומציה, מציינים את השלב שממנו רוצים להתקדם (sourcePhase). קטע ה-stanza‏ rules שמוצג כאן מופיע בתוך הגדרת האוטומציה.

rules:
- advanceRolloutRule:
    id: "[RULE_ID]"
    sourcePhases: ["[START_PHASE]", "[START_PHASE]"...]
    wait: [WAIT_TIME]

כאשר:

  • [RULE_ID]

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

  • [WAIT_TIME]

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

    ערך ברירת המחדל הוא 0, כלומר אין זמן המתנה. הערך המקסימלי הוא 20160m (או 14 ימים).

  • ["[START_PHASE]", "[START_PHASE]"...]

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

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

הגדרת repairRolloutRule כלל אוטומטי

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

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

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

הפסקה rules שמוצגת כאן נכנסת לתוך הגדרת האוטומציה.

rules:
- repairRolloutRule:
    id: "[RULE_ID]"
    phases: [PHASES_TO_REPAIR]
    jobs: [JOBS_TO_REPAIR]
    repairPhases:
    - retry:
        attempts: [NUMBER_OF_ATTEMPTS]
        wait: [WAIT_TIME]
        backoffMode: [LINEAR | EXPONENTIAL]
    - rollback:
        destinationPhase: [PHASE_NAME]
        disableRollbackIfRolloutPending: [true | false]

כאשר:

  • [RULE_ID]

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

  • [PHASES_TO_REPAIR]

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

  • [JOBS_TO_REPAIR]

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

  • [NUMBER_OF_ATTEMPTS]

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

  • [WAIT_TIME]

    הוא משך הזמן להמתנה בין ניסיונות חוזרים. לדוגמה, 1m למרווח של דקה אחת. חובה לציין את יחידת הזמן (m במקרה הזה).

    אם mode הוא linear, המרווח הזה זהה לכל ניסיון חוזר. אם mode הוא exponential, המרווח גדל בכל פעם. (modeתיאור נוסף)

  • backoffMode

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

    לדוגמה, אם WAIT_TIME הוא דקה אחת, ו-backoffMode מוגדר ל-EXPONENTIAL, אז הזמן בין הכשל לבין הניסיון החוזר הראשון הוא דקה אחת, הזמן בין הניסיון החוזר הראשון לשני הוא 2 דקות, והזמן בין הניסיון החוזר השני לשלישי הוא 4 דקות.

  • rollback

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

  • [PHASE_NAME]

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

  • disableRollbackIfRolloutPending:

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

ביטול של repairRolloutRule הרצת אוטומציה

אם מריצים אחת מהפקודות הבאות בהשקה, האוטומציה של repairRolloutRule מבוטלת:

דוגמה

הדוגמה הבאה מציגה הגדרת אוטומציה עם repairRolloutRule:

apiVersion: deploy.cloud.google.com/v1
kind: Automation
metadata:
  name: regular-repair/regular
description: repair regular rollouts
suspended: false
serviceAccount: (REDACTED)
selector:
  targets:
  - id: t1
rules:
- repairRolloutRule:
    id: "repair-rollout"
    repairPhases:
    - retry:
        attempts: 3
        wait: 1m
        backoffMode: LINEAR
    - rollback:
        destinationPhase: "stable"

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

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